### Rozdział 42. Testowanie funkcji – jak sprawdzić, czy Twoja strona „działa naprawdę”, zanim pokażesz ją światu

Moment tuż przed publikacją jest jak ostatni przegląd auta przed długą trasą. Wszystko wygląda świetnie: lakier błyszczy, wnętrze pachnie nowością, mapa trasy jest gotowa. Ale czy światła na pewno świecą? Czy hamulce reagują? Czy w bagażniku jest koło zapasowe? W świecie stron internetowych ten „przegląd” to testowanie funkcji: linków, formularzy, koszyków, płatności, wyszukiwarek, wersji mobilnej i dziesiątek drobiazgów, które decydują o tym, czy użytkownik dojedzie do celu – i czy zrobi to bez frustracji.

W tym rozdziale przeprowadzę Cię przez kompletny proces testowy: od ręcznego „przejścia ścieżek” jak zwykły użytkownik, przez automatyzację ważnych przypadków, po testy na różnych urządzeniach, przeglądarkach i w warunkach „realnych” (słaby internet, zablokowane ciasteczka, brak JavaScript). Pokażę też, jak mądrze udokumentować testy, by nic nie umknęło, oraz jak przygotować się na e‑commerce i integracje, gdzie liczba ruchomych elementów rośnie.

#### Zacznij od ścieżek użytkownika: co musi zadziałać „od A do Z”
Zanim włączysz narzędzia, wejdź w buty użytkownika. Zdefiniuj 3–5 najważniejszych ścieżek i przejdź je jak człowiek, nie jak programista:

- Wejście na stronę główną → kliknięcie w wyróżnione CTA → wypełnienie formularza → strona z podziękowaniem → e‑mail powitalny.
- Wejście z reklamy na landing → scroll → klik w cennik → wybór planu → formularz płatności (jeśli sprzedajesz).
- Przejście do bloga → otwarcie artykułu → klik w zasób (lead magnet) → zapis → dostęp do materiału.
- Wyszukanie produktu/usługi → filtrowanie → dodanie do koszyka → checkout.

Na tym etapie notuj nie tylko „błędy”, ale każde potknięcie: przycisk przesunięty poza ekran, formularz z niejasnym komunikatem, zbyt długi czas ładowania. W testach funkcjonalność to jedno, ale „odczucie” jest równie ważne.

#### Linki i nawigacja: żadnych martwych końców
Link, który nie działa, to jak drzwi prowadzące w ścianę. Dlatego:

- Ręcznie kliknij wszystkie linki w menu, stopce i na kluczowych podstronach. Zwróć uwagę, czy otwierają się tam, gdzie obiecują (np. zewnętrzne w nowej karcie).
- Sprawdź linki „kontekstowe” w treściach (artykuły, sekcja „Zobacz też”, przyciski obok formularzy).
- Upewnij się, że linki z parametrów kampanii (UTM, gclid) zachowują się poprawnie – po przejściu do kolejnych kroków parametry nie giną, jeśli są potrzebne do analityki.
- Automatycznie przeskanuj witrynę narzędziem do weryfikacji linków (np. Broken Link Checker, Screaming Frog). To wyłapuje odnośniki głęboko w archiwach.

Zasada: każdy link ma cel, a każdy cel da się osiągnąć bez „ślepych zaułków”.

#### Formularze: dane, walidacja, komunikaty i dostarczalność
Formularz to najczęściej Twój kanał konwersji. Traktuj go jak urządzenie medyczne: musi działać perfekcyjnie.

- Walidacja po ludzku: wpisz złe adresy e‑mail (bez „@”, z polskimi znakami), krótki numer telefonu, pominięte wymagane pola. Komunikaty błędów powinny być jasne, przy polach, nie ogólne.
- Stan po błędzie: czy formularz zachowuje poprawnie wpisane dane, by użytkownik nie musiał wprowadzać wszystkiego od nowa?
- Zgody i RODO: checkboxy działają, linki do polityki prywatności otwierają się poprawnie, a brak zgody blokuje wysyłkę z czytelnym komunikatem.
- Po prawidłowej wysyłce: strona z podziękowaniem ładuje się szybko i mówi, co dalej. Upewnij się, że e‑mail potwierdzający dochodzi w ciągu minut (sprawdź skrzynkę główną i „Oferty/Spam”).
- Integracje: zapis trafia do CRM/ESP z prawidłowymi tagami i źródłem (UTM). Przetestuj to na żywych rekordach testowych, nie tylko w logach.

Jeśli masz warianty formularzy (landing vs. kontakt), przetestuj każdy z nich osobno.

#### E‑commerce: koszyk, kupony, płatności, e‑maile transakcyjne
Tu w grę wchodzą pieniądze – margines błędu powinien być minimalny.

- Dodawanie do koszyka: testuj różne warianty (rozmiar/kolor), stany magazynowe (ostatnia sztuka, brak na stanie), zachowanie po usunięciu produktu.
- Kupony i rabaty: kody działają tylko tam, gdzie powinny; pokazują poprawne naliczenie i warunki (min. wartość koszyka, wykluczenia).
- Koszty dostawy: poprawne stawki po przekroczeniu progów, właściwe metody dla regionów, jasne czasy dostawy.
- Checkout: opcje płatności (karta, BLIK/przelew, PayPal, Apple/Google Pay) – potwierdź transakcje w środowisku testowym (sandbox) i z jedną „małą” realną płatnością, jeśli to możliwe.
- Błędy płatności: kontrolowane scenariusze (odrzucona karta, brak środków). Czy komunikat jest zrozumiały? Czy użytkownik może spróbować ponownie?
- E‑maile transakcyjne: potwierdzenie zamówienia, faktura, powiadomienia o statusie. Czy są spójne z marką, czy dochodzą i linkują do właściwych miejsc?
- Zwroty i anulacje: przynajmniej jeden testowy zwrot. Zobacz, jak działa proces i jakie komunikaty dostaje klient.

Jeśli korzystasz z operatorów płatności, upewnij się, że webhooki/statusy aktualizują zamówienia w czasie zbliżonym do rzeczywistego.

#### Różne urządzenia i przeglądarki: świat nie kończy się na Twoim laptopie
Twoi użytkownicy będą przychodzić z telefonów, tabletów, starych laptopów, różnych systemów. Dlatego:

- Mobilnie: sprawdź kluczowe ścieżki na co najmniej dwóch popularnych rozdzielczościach (np. iPhone 13/14, średni Android). Klikalność przycisków, sticky elementy, formularze „na kciuk”, brak nachodzących elementów.
- Przeglądarki: Chrome, Safari, Firefox, Edge. Zwróć uwagę na wideo, fonty, animacje, inputy formularzy. Safari bywa najmniej wyrozumiałe.
- Tryb ciemny (jeśli obsługiwany): czy kontrasty są czytelne, logo nie „znika”, obrazy nie psują kompozycji.
- Warunki „trudne”: symuluj wolne łącze (DevTools → Throttling), wyłącz ciasteczka, sprawdź zachowanie przy zablokowanym JS (dla krytycznych informacji). To urealnia obraz.

Celem jest nie „idealność w labie”, ale przewidywalność w realnym świecie.

#### Szybkość i stabilność: czy strona oddycha lekko
- Core Web Vitals na kluczowych stronach (główna, landing, artykuły, checkout). Zwróć uwagę na LCP (główny obraz), CLS (skakanie układu), INP (responsywność).
- Obrazy: ciężar, format (WebP/AVIF), lazy‑load, rozmiary zgodne z kontenerem.
- Skrypty: czy nie blokują renderu? Czy nie duplikujesz bibliotek (np. dwóch wersji jQuery lub dwóch pikseli)?
- Caching i CDN: aktywne dla statycznych zasobów, rozsądne nagłówki cache.

Szybkość to funkcja – użytkownik ją czuje bez otwierania raportów.

#### Dostępność: funkcje dla wszystkich użytkowników
- Klawiatura: czy da się przejść przez formularz i UI bez myszy? Focus jest widoczny?
- Alt‑teksty: na kluczowych obrazach, ikonach przycisków. Etykiety aria dla elementów interaktywnych.
- Kontrasty i wielkość czcionek: szczególnie w placeholderach formularzy i linkach w stopce.
- Czytelne błędy: komunikat mówi, co i jak poprawić, a nie „Błąd walidacji 422”.

Dostępność to nie „dodatek”, to część jakości.

#### Testy automatyczne: utrzymanie jakości, gdy strona rośnie
Ręczne sprawdzanie jest niezbędne, ale automatyzacja chroni przed „cofnięciami” po kolejnych wdrożeniach.

- Testy E2E (np. Cypress/Playwright): przynajmniej trzy scenariusze krytyczne
  - Landing → formularz → strona „Dziękuję”.
  - Blog → zapis na lead magnet → otrzymanie e‑maila (w testach potwierdź event/odpowiedź API ESP).
  - Produkt → koszyk → checkout w sandboxie.
- Testy dostępności (np. axe-core) jako krok w pipeline: wyłapują podstawowe problemy WCAG.
- Lighthouse/PSI w CI: minimum próg „żółto‑zielony” dla Performance/SEO/Best Practices.
- Monitorowanie uptime i błędów: proste health‑checki + zbieranie błędów JS (Sentry) i 500‑ek po stronie serwera.

Automatyzacja nie zastąpi oka człowieka, ale daje „siatkę bezpieczeństwa”.

#### Analityka i tagi: czy mierzysz to, co trzeba
- Sprawdź, czy piksel/Tag Manager ładuje się na wszystkich stronach, a zdarzenia (view, submit, purchase) odpalają się raz i z poprawnymi parametrami.
- Zduplikowane eventy to częsty problem: podwójne biblioteki, ten sam trigger w dwóch miejscach. Efekt? Zafałszowane dane.
- Zgody cookies: baner działa, preferencje zapisują się, a skrypty reklamowe uruchamiają się dopiero po akceptacji.

Bez wiarygodnych danych trudno oceniać, czy „działa”. To też element testów.

#### Dokumentacja testów: lista kontrolna, wyniki, decyzje
Dobra dokumentacja to Twoja pamięć zbiorowa:

- Prosta lista kontrolna (checklista) w arkuszu lub narzędziu do zadań: ścieżki, testy przeglądarek, formularze, płatności, e‑maile, analityka, dostępność, prędkość. Kolumny: status, kto testował, uwagi, link do zrzutu.
- Zasada „dowód lub nie było”: do każdego błędu zrzut ekranu lub krótki clip, opis kroków do odtworzenia, środowisko (urządzenie/przeglądarka).
- Retesty: po poprawce odhacz „sprawdzone” z datą i wersją wdrożenia.
- Raport przed premierą: jedno miejsce z listą otwartych ryzyk (jeśli są), decyzją „go/no‑go” i planem monitoringu po starcie.

To oszczędza nerwy przy każdym deployu i przydaje się, gdy zespół rośnie.

#### „Dzień startu”: test w produkcji, ale pod kontrolą
- Soft launch: przez pierwsze godziny ogranicz ruch (np. brak kampanii płatnych), monitoruj logi błędów, formularze, płatności, e‑maile.
- Kanał „war room”: szybka komunikacja (Slack/Teams), żeby naprawiać drobne rzeczy w locie.
- Mapy ciepła i nagrania sesji: włącz na kluczowych stronach – wcześnie zobaczysz, gdzie ludzie utknęli.

Udany start to nie cisza – to szybkie wychwycenie szmerów.

#### Najczęstsze potknięcia i szybkie remedia
- Działające „na sucho”, a psujące się „na żywo” webhooki płatności → dodaj logowanie odpowiedzi i alerty na błędy statusów.
- Formularz działa, ale e‑mail nie przychodzi → sprawdź nadawcę, SPF/DKIM, rate limit ESP, folder „Oferty/Spam”. Dodaj link „wyślij ponownie”.
- Znikające UTM po przejściach → przekazuj je w linkach lub przez sessionStorage i doklejaj do kolejnych kroków.
- Zduplikowane eventy analityczne → jeden kontener GTM, audyt triggerów, wyłącz testowe środowisko na produkcji.
- Elementy nachodzące na mobile → przegląd sticky headerów/banerów cookies/pop‑upów, korekta z-index i breakpointów.

To drobiazgi, które ratują konwersję.

### Podsumowanie rozdziału

Testowanie funkcji to nie formalność, tylko ostatnia warstwa zaufania. Użytkownik widzi stronę, ale „czuje” proces: płynne linki, formularz, który pomaga a nie karze, koszyk bez niespodzianek, płatność, która przechodzi bez dramatu, i e‑mail, który przychodzi wtedy, kiedy ma przyjść. Sprawdź najważniejsze ścieżki ręcznie jak człowiek, podeprzyj to automatyzacją krytycznych przypadków, odpal testy na urządzeniach i w przeglądarkach, a na koniec wszystko opisz. Z takim podejściem start nie jest skokiem do zimnej wody – to zanurzenie w kontrolowanym akwenie. Dzięki temu możesz skupić się na tym, co najważniejsze: dostarczać wartość i rozwijać biznes, mając pewność, że fundamenty działają bez zarzutu.